Handle insert_table errors
#129
Conversation
|
I like the solution although it doesn't quite follow the pattern we're using everywhere else. If you check the api/execution.py file you'll see this common pattern of try catch key error and then raise of dune error. Realistically we should improve the error classifications, but it might be good to try to follow the similar pattern for now so we can find all the things that need changing after improvements have been made. I would also prefer to raise here instead of returning something that needs to be matched on. At least until the whole library is working that way. |
|
@bh2smith throwing a |
|
Looks good for now! I think improving error handling as a whole could be reserved for a follow up PR. let's get this in for now and address that separately. Let me know if you're happy with this and we can get it released. |
There was a problem hiding this comment.
Approving because this is definitely an improvement and probably ok for now, however, I think this isn't happening in the correct place.
Ideally, we should check the HTTP status code after making a call to the API and handle the response accordingly. When we get a 4XX or 5XX, we could raise an error with details about it rather than letting the response flow as if it was successful.
Fix for issue #128
Attempting to resolve the issue of unhandled insert errors with a new dataclass
InsertTableErrorResultwhich can handle theerrorfield.This is most likely not the most elegant way to handle this. I'm open to suggestions :)